Business requirements is about creating structured representations of business activities, used to communicate how a new or existing business process should work. In IT projects business requirements is often a precursor to designing and building a new business application/system, or changing an existing one, and often sets the context for business process modeling, requirements analysis. The business requirements may encompass pre-requisites for both functional requirements and non-functional requirements that are desirable in the new or to be changed system. Business requirements are fairly standardized in their content structure and often referred to as Business Requirements Definition document or BRD. The emphasis in a business requirement document is on business processes and analysis outlining required change, and less on how to achieve using IT development. However, since IT based solution to deploying a new business requirement is common and may be required to work with existing IT systems and IT infrastructure, business requirements may therefore be accompanied by what is popularly referred to as Systems Requirements Definition or SRD or Systems Requirements specification, which complements the business requirements, and defines the technology related requirements.
Contents |
Business requirements in the context of software engineering or software development life cycle, is about eliciting and documenting business requirements of business users such as customers, employees, vendors, etc. early in the development cycle of an information system to specifically design and develop the future business system. Capturing business requirements is often carried out by business analysts, who analyze business activities and processes, and often study As-is process to define a target To-be process. Business requirements often include
| Benefit [1] | Description |
|---|---|
| Reduce Project failure | Structured explanation of a business process or method defined early in the life cycle helps reduce project failures that occur due to misaligned or misrepresented requirements leading to failure of user expectations. |
| Connects to broader business goals | Well-defined business requirements help lay out a project charter, a critical step in executing business strategy or business goals, and to take it to the next logical step of developing it into an IT system. This helps monitoring overall project health and provides for positive traction with key project stakeholders including sponsors. |
| Consensus creation and collaboration | The benefit of a structured format typical of business requirements documentation helps create positive consensus and better collaboration where the business stakeholder group might be a large cross-functional team, distributed geographically. |
| Saves costs | Good quality of business requirements when captured early on not only improves success of a project but also save overall costs associated with change requests, and related investments in training, infrastructure, etc. |
Business requirements are typically captured or owned by business analysts, often in collaboration with other stakeholders, which include subject matter experts, customers, end users, technology architects, ethnographers and user surveyors, usability experts, UI designers and in some cases senior management executives who directly sponsor such activities. Experts with business knowledge, industry domain knowledge, and technical knowledge are especially critical to elicit and define business requirements, including conducting business analysis. Often for a project there is a project sponsor and a project charter, which defines scope of business requirement. Typically, a business analyst owns the business requirements and manages them over time. Business analysts are usually like internal or in-house consultants. Different bodies representing business analysts have different models defining essential competencies of business analysts, which broadly cover
| Typical BRD Structure - [2] |
|---|
|
The most popular format to capture business requirements is what is popularly referred to as Business Requirements Document (BRD). The intent behind these sorts of descriptive documents is to help automate either parts or the entire business process into an IT system. Hence, BRD documents are complemented with a systems reference document (SRD) that details the technology performance and infrastructure expectations including any technology requirements pertaining to quality of service, be it performance, maintainability, adaptability, reliability, availability, security, scalability etc. Often, the BRD specifications are also referred to as functional requirements, while the technology related aspects as non-functional requirements. These standard formats are captured using popular templates such as BRD, SRD/SRS, Use Cases, Flow charts, data flow diagrams, some complementing the other. There are a variety of tools to carry out each of these modeling activities.
At a broader level, format and standardization could pose difficulties if it is not structured for a specific business problem or area. Again, it needs to have sufficient flexibility that allows an author to customize the format, without deviating from the need to provide consistency, traceability, usefulness and without breaking down the larger business goals, especially in the case of complex, cross-functional business situations. There is the risk of misinterpretation of textual content that leads to mismatch of end deliverable and initial expectations. Retaining context and supplying relevant background descriptions is a critical part of these formats. While a majority of templates use a structured format, a few others use story telling as a way to capture scenarios to fully capture finer nuances of a complex business process, which otherwise tend to get ′lost in translation′ when overburdened with structure.
| Category | Tools |
|---|---|
| Document | Microsoft Office (Word, Excel, PowerPoint), Openoffice, etc.; Wordpress blog tools, etc.; Social tools - Facebook, Twitter, Email - Outlook, Eudora, Thunderbird, etc.; Online docs - Google docs, Scribd, Slideshare, etc.; |
| Flowchart | Microsoft Visio (with UML add-in); PowerPoint, etc. |
| Business process modeling | Rational Requisite Pros and Rational Rose (from IBM), Business Process Architect (from Visual Paradigm), EA (from Sparx Systems) |
| Painting and image tools | Adobe Illustrator, Photoshop, Corel Draw, etc. |
| Prototyping/Mockup/Wireframing | Axure RP, iRise, Serena, ProtoShare, LucidChart. |
| Requirements management and Business Analysis | Test Director (for Traceability), Rational Suite from IBM (end to end requirements management suite), HP Quality Center (for test cases and testing), Psoda (Cloud based requirements management tool) |
Prototyping with early stage stakeholder testing is an important way to assess the completeness and accuracy of captured business requirements. Especially since various stakeholders who help define requirements come in early and hand over to project development teams who build the business system, and others who test and evaluate final deployed system or working solution, it is very important to have traceability of requirements. Hence a well administered process to control the entire process of business requirements, right from which template to use to who fills what section and when, who modified next and released as which version, etc. is an important aspect of managing business requirements. Business requirements scope is not necessarily limited to the stage where it serves to define what needs to be built as a business system. It goes beyond to envisage, how a running business system is managed and maintained, to ensure it stays aligned to business goals or strategy. In that sense, a business requirements document can be viewed as a living document, meaning it is constantly revised, albeit, in a controlled fashion. Also, having a standardized format or templates that are designed for specific business functions and domains can ensure completeness of business requirements, besides keeping the scope fixed and clear.
Business requirements are often stuck due to large stakeholder base involved in defining the requirements, where there is a potential for conflict in interests. The process of managing and building consensus can often be delicate and even political by nature. A lesser challenge, though common, is that of distributed teams with stakeholders in multiple geographical locations. It is natural that sales staff is closer to their customers, while production staff is closer to manufacturing units; finance and HR, including senior management are closer to the registered head quarters. A system for example that involves sales and production users may see conflict of purpose – one side may be interested in offering maximum features, while the other may focus on lowest cost of production. These sorts of situations often end in a consensus with maximum features for a reasonable, profitable cost of production and distribution.
Some common solutions that address these challenges include, early stage stakeholder buy-in achieved through demonstration of prototypes and jointly working to co-create, etc. Stakeholder workshops that are either facilitated sessions or simple huddled discussions help in achieving consensus, especially for sensitive business requirements and where there is potential conflict of interest. Complexity of a business process is therefore a factor of such interest conflicts among stakeholders or due to an inherently complex business process, such as one where there is a lot of specialized knowledge required to comprehend viz. legal, regulatory requirements, even internal company wide guidelines such as branding, corporate commitments to CSR, etc. Business requirements is not just about capturing the ‘what’ of a business process along with its ‘how’ to provide context, in fact, in addition to the what and how, it is also about how the business requirements get translated into designing and building a working system. Here, at this stage, business requirements have to acknowledge and supplemented with technical details and feasibility. Not always do you have a solution built custom for every new set of business requirements. There are often standardized processes and products which with some tweaking or customization serve to address the business requirements. The challenge is when the target business system is constrained by a specific technology choice or a budget or available products already deployed. Last, but not the least, is the challenge of standardizing on a format to capture business requirements. If not achieve standardization for a given industry, at the very best, standardizing within an organization can be a challenge. Multiple projects with multiple formats that lead to variation in structure and content of a requirements document renders these ineffective from a traceability and manageability perspective. In fact, when creating a template for use in a cross-functional requirements gathering exercise, different roles with complementary knowledge may find it difficult to work with a common format. Here, it is important to ensure, it is understood by non-specialist or non-expert stakeholders, at the same time, allow via Appendices and additional attachments for experts to dive into their area of specification. Addressing various nuances and arriving at a best fit remains the single biggest challenge to effective requirements.
Creating pictorial representations and interactive simulations with images, wireframe layouts and interactive, clickable prototypes can help cut the noise arising out of interpreting textual descriptions. Also, visual modeling of requirements via prototyping, etc. portrays a WYSIWYG real feel to an application and helps create consensus more rapidly. Prototypes are often created as mockups and wireframes which might be just snapshot views, static representations. Dynamic, realistic prototypes traditionally require some amount of programming effort to create a more detailed, interactive and richer prototype of the application. The choice between a quick and dirty paper prototype on one hand and a completely finished WYSIWYG interactive prototype is based on the sensitivity and need of stakeholders involved. For a simple business requirement with fairly straightforward processes and low in complexity, a quick and dirty prototype serves the purpose. For more sensitive business requirements where there is a likely political angle to stakeholder interests or well known viewpoints, or complexity of process, a more detailed, dynamic prototype is more appropriate. The challenge to prototyping is often the time required and cost of prototyping effort, especially to create high-fidelity prototypes (also see low-fidelity prototypes). In practice, however, not every project’s business requirements are supported by prototypes, especially detailed, clickable prototypes. Primary reasons for not doing prototypes, especially the detailed, interactive one requiring custom development effort, is either it takes too much effort and time, nullifying the basic premise of early buy in or evaluation. Prototypes often tend to be used primarily to demonstrate user experience, but doesn’t capture underlying business logic or rules. Process flows to illustrate business activities is often captured separately using flowchart style layouts. Screen prototypes and mockups complement these flowcharts depicting business activities. Additional simulation using dummy data or duplicate systems is also used to validate and demonstrate business rule behavior, which is often not visible to end users or is underneath the click of a button, or how a tabular chart loads with what data using what layout. Business process simulation is an area in its own right and is not within scope of prototyping. There are full-fledged XML variant business process languages and engines to run these. However, it is pertinent to mention these aspects of simulation to highlight the complete extent and scope of a business requirements document.